Subject: Set_Partner_ID and Initialization_Queue

From: "Mel Jones (Tie: 444-4363)" <[email-masked]>
Date: Fri, 5 Nov 93 14:35:14 EST

Frank:

Thanks for the note -- it's nice to know someone out there is thinking
about this stuff.

The main reason that the Sets are on the Initialization_Queue is
not so they can be non-blocking (actully, none of them should
block at all), but so they can be correctly serialized.  The
problem scenario if you don't put them on the queue is this:  The
program issues an Allocate which gets OPERATION_INCOMPLETE.
There is no state change so the program can now issue other
destination_information Sets (which might over-ride Sets that
were issued before the Allocate).  This gets messy and
complicated quickly for the programmer (and implementation) to
keep track of.  Putting the dest-info Sets on same queue as the
Allocate fixes the problem because after the Allocate no other
Set calls can be issued.

To sum, the point of the above background is that the Sets aren't
placed on the Initialization_Queue to be non-blocking; they're
put there to serialize.

That doesn't remove the possibility that Set_Partner_ID could be
the *first* Set that would actually block.  This was discussed as
an option at the last CIW (and had come up even earlier back in
the very first discussions of what Set_Partner_ID would like).
The design that we have right now (just store the input string;
don't do anything that would block the program) is there for
three reasons:

 1. None of the other Sets do anything that would block, so this
    would violate the "feel/style/uniformity of the interface."

 2. Some implementations of CPIC are built on top of existing
    CRM implementations (e.g., LU 6.2 or OSI).  In this case, there
    is already an existing native conversational interface that will
    be supported (and which the product will update to support
    directory -- for example, on LU 6.2, a new flavor of Allocate*
    that would let the program identify its partner with a DN, etc.)
    These implementations want to handle the partner_ID like they
    handle all other sets -- lightweight calls that set up the
    parm that then gets passed down to the CRM where the real work is
    done.  If the Set goes to the directory, they would be forced
    to put the same function in two places (in CPIC as well as in
    the native interface).  By leaving the directory access in the
    Allocate the implementations get their choice -- they can do it
    in CPIC or, if they've built the function into the underlying
    CRM stack, they can pass it on down.

 3. There wasn't really a lot of value-add for the program to be
    able to access the directory prior to Allocate -- the real value
    is to issue the Extract_call after the allocate and find out what
    the information used was.  If the program *really* needs to
    see the list of bindings prior to the Allocate (which is a
    relatively sophisticated program), it can always go to the
    local directory interface itself and pass the binding_list in
    on the Set_Partner_ID.

I hope this helps.

Regards,
Mel

* Discussion of a new flavor of Allocate for LU 6.2 with a DN
(allocate_PID) occured at the December92 and March93 CIW.
There's a suggested syntax in the paper that was distributed at
both those meetings.

- - - end of note  - - - - - -